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Abstract 


Based on tamper-evident devices, i.e., a type of distinguishable, 
sealed envelopes, we put forward weak bit-commitment protocols which 
are UC-secure. These commitments are weak in that it is legitimate 
that a party could cheat. Unlike in several similar lines of work, in our 
case, the party is not obliged to cheat, but he has ability to cheat if and 
when needed. The empowered party is the sender, i.e., the protocols 
are also sender-strong. 

We motivate the construction of such primitives at both theoretical 
and practical levels. Such protocols complete the picture of existent 
receiver-strong weak bit-commitments based on tamper-evidence. 

We also show that existent receiver-strong protocols of the kind are 
not EUC-secure, i.e., they are only UC-secure. Further, we put forward 
a second formalisation of tamper-evident distinguishable envelopes 
which renders those protocols and the protocols herein EUC-secure. 

We finally draw most implication-relations between the tamper- 
evident devices, our weak sender-strong commitments, the existent 
weak receiver-strong commitments, as well as standard commitments. 

The mechanisms at the foundation of these primitives are lightweight 
and the protocols yielded are end-to-end humanly verifiable. 
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1 Introduction 


Why Tamper-Evidence and UC? A way to ensure strong security 
guarantees of a primitive is to show that it is secure in the UC (universal 
composability) framework [7, 9]. In this formalism, the security proven in 
one single session is inherited when the protocol is executed over multiple 
parallel or sequential sessions. If only a minority of the participants are 
corrupted in a polynomial-time multi-party computation, then the corre- 
sponding functionality can be UC-realized. Another way to achieve such a 
strong ideal emulation is to give access to all participants to an extra helping 
functionality called setup [7]. The latter empowering of parties yields the 
so-called UC hybrid models. (The reader can consult Appendix A, for a 
short summary of the UC frameworks and of the techniques in a UC proof.) 

UC hybrid models, with setups of tamper-evident (TE), tamper-resistant 
(TR) devices and other means of restricted/isolated communication /computati- 
on, have been employed to UC-realize bit-commitments, oblivious transfers, 
coin flipping, polling schemes [17, 19, 16, 20, 21, 23, 22, 4], etc. For example, 
in [17], Katz opens for the creation and exchange of stateful tamper-proof 
hardware tokens used in a commitment protocol, which is UC-secure under 
the DDH assumption. In [10], two-party computation can also be UC- 
realized, using only stateless tokens and assuming the existence of oblivious 
transfer. Mateus and Vaudenay [19] allow a more permissive flow of hardware 
TR devices from creators to users and backwards than the one in [10], yet 
they obtain very similar results in their trusted agent model [19]. Similar 
protocols are constructed by Moran and Naor, in [23], using tamper-resistant 
hardware tokens that can be passed in one direction only. 

We note that the distinction of having UC-commitments which place 
the strength on the sender or, on the contrary, place their strength on the 
receiver has been underlined [23] within this context of using tamper-resistant 
hardware as UC-setup. Based on sealed envelopes and sealed locks, i.e., 
simpler, not tamper-resistant, but just tamper-evident devices, Moran and 
Naor designed UC-secure protocols [22, 20, 21]. All their constructions 
empowered the protocol-receiver with cheating powers, i.e., the sender was 
“weak”. In that line, the tamper-evident devices were created by the receiver 
of the commitments; we will refer to this as receiver-strong. 

Moran and Naor proved that a type of distinguishable envelopes were 
the least complex tamper-evident devices that would entail UC-secure weak 
bit-commitments (WBC) [22] (i.e., they put forward a hierarchy of simple 
tamper-evident devices, of which some were not sufficient for WBC). 
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In this paper, we will work in the UC framework as it was introduced 
in [7], ie., the communication channels are assumed to be secure. Another 
possibility would be to work in the UC model as it was refined in later 
years [9], where the channels are insecure but authentication-of-origin needs 
to be assumed on top: enforced via an extra setup (which is most often 
the case), or built-in into the protocols. Like in the case of similar works 
reminded above, our results hold in the first mentioned UC model [7], and 
modification would be needed to operate in the second [9]. 


Why Sender-strength (SS)? Why weak bit-commitments (WBC)? 
Why SS WBC? “Is it preferable to trust Vic or Peggy? We do not know, 
but it sure is nice to have the choice. [5]”; this statement by Brassard, Chaum 
and Crépeau, enunciated in their seminal work on commitments, is still 
standing today. In fact, Moran and Naor in [22] formulate the open question 
of finding such lightweight, UC-secure (weak) bit-commitment protocols that 
in turn place their strength on the sender’s side, i.e, sender-strong. 

In fact, there are several practical and theoretical reasons that motivate 
the existence of weak bit-commitments and also specific ones calling for 
their sender-strong version. Sender-strong weak bit-commitments are firstly 
interesting in traditional theoretical lines (i-e., outside of the UC-framework), 
where they are easier to construct (see Section 3.5). 


e In trapdoor commitments [15], the output of the commitment-phase 
conceals the committed value from an informational theoretical point of 
view. But, the sender is only computationally bound to this committed 
value and, when given a trapdoor, he can in fact open a commitment 
in any possible way. Such primitive are sufficient [15] (i.e., no perfectly 
binding commitment is needed) to build more interesting cryptographic 
protocols in traditional lines. From this set of protocols, we mention 
concurrently secure and resettable identification schemes [2], and de- 
niable authentication protocols [14, 15]. The above protocols have at 
their basis the construction of specialized ZK proofs. In our case, we 
move from the knowledge of a trapdoor to empowering the sender via 
a convenient transcript. Not surprising, this sort of commitments are 
also used to build special kinds of ZK proofs. This is detailed in the 
point presented below. 


e In a different setting, in [5] Brassard et al. showed that “chameleon” 
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bit-commitments? would imply, in traditional cryptography, zero- 
knowledge (ZK) proofs of knowledge where the verifier sends inde- 
pendent bits. For these ZK proofs of knowledge (PoK) to be provable 
secure against adaptive adversaries, content-equivocable bit commit- 
ments are further needed [1] (i.e., in order to equivocate, the sender 
has at hand only a transcript of the communication between him and 
the receiver and nothing else). 


Practice also imposes situations of sender-strength. For instance, con- 
sider the cases where the sender/committer should not have to trust the 
receiver in any way (e.g., it should only be the sender/committer who is 
required to create and seal the envelopes used in an envelope-based com- 
mitment scheme). This may be the case if the receiver is thought to have 
access to side-channels attacks (i.e., the receiving voting authority uses some 
special techniques to change the values hidden inside envelopes without 
resealing). Or, further, take the example of anonymous auctioning protocols 
[11, 18, 13], where the receiver /auctioning-house and the sender/auctioneer 
mutually ignore their identities throughout most phases of the protocol. 
Hence, the receiver Bob should not start by sending to some committer 
Alice the envelopes to be used in her commitment (as Bob ignores Alice’s 
existence), but Alice should in turn commit to the maximum bid that she 
intends to place by possibly using self-made, tamper-evident “envelopes”. 


Contributions & Further Motivation. In this paper, we pursue the 
following directions. Primarily, we create sender-strong UC-secure WBC, i.e., 
weak bit-commitments that place the (adversarial) strength on the committer 
side and that are UC-secure. For this, we use UC setup slightly different 
to that of [22]. I.e., for reasons to be discussed, we firstly needed to put 
forward a new formalisation of distinguishable envelopes. In Section 2.2, we 
also describe a hierarchy of ideal functionalities for sender-strong weak bit- 
commitments and then we UC-realize them. In this fashion, we can relate the 
WBCs UC-realized herein both with traditional weak bit-commitments [1] 
of theoretical importance (e.g., see our Eg aa ers and with weak bit- 
commitments UC-created in [22] with distinguishable envelopes (see our 
i ete The differences between these target-functionalities lie 


mainly in learning that equivocation is possible (yet not obligatory) at the 
—WBC : —WBC 
commitment phase (Fi ceranteomaenene) or the opening phase (Fi araapopeitae) 


3These are commitments where the sender could cheat at the decommitment phase if 
given extra information. 
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vs. cheating only when the committer has not yet been caught abusing the 
g—-WBC 
protocol (FiucapaThenMaychadt,)* 

We present two functionalities of distinguishable envelopes, differing in 

that the second one models envelopes created for a designated recipient. We 
now motivate the choices made with respect to this. There are many ways to 
formalise tamper-evident containers [22], reflecting the different requirements 
of the possible physical implementations of such devices. Moran and Naor 
model distinguishable envelopes which allow for creator-forgeability (i.e, the 
creator of the envelope can re-seal it without breaking the tamper-evidence). 
We argue however that sender-strong (weak) commitments only make sense 
if they are computationally hiding and somewhat binding, i.e., the receiver 
has no special abilities and the sender could equivocate his openings, if and 
when needed. Hence, the amplified partially hiding and partially binding 
weak commitments in [22] would not serve well the sender-strong setting. 
Moreover, we conjecture that it is not possible to construct UC-secure, 
hiding sender-strong bit-commitment protocols, using the TE envelopes 
n [22]. Thus, herein, we do not allow the resealing of envelopes by their 
creator. Le., we model seal-once distinguishable tamper-evident envelopes 
(or, envelope allowing one-seal only), and [22] formalises a multi-seal TE 
envelope. 
Note: It may seem easy to construct commitments using this formalisation, 
but —in the UC framework- this is not trivial at all. We also show eventually 
that many of these formalisation “collapse” in one another. Please see 
Section 3.5 and Section 4 for details. 


We noted that the protocols built with envelopes 4 la Moran and 
Naor [22] were not EUC-secure, i.e., only UC-secure. We concluded that if we 
further allowed for purported destinator of envelopes, then the corresponding 
DE-based protocols obtained both here and in [22] lead to protocol which are 
EUC-secure and not only UC-secure. Our second distinguishable envelope 


: : tedDE : 
functionality (Fercéea1 +) Serves this very purpose. 


We finally draw several implication-relations between the following: 
our first functionality of distinguishable envelopes (F2%,.), the standard 
UC-functionality of bit-commitment (F?°) and those of WBC (already 
existing and newly introduced herein). 


Note: Part of this material was presented in [3]. Notably, none of the 
proofs or the extended explanations on the protocols or functionalities were 
included in that version; these are introduced for the first time in here. Also, 
the OpenEnablesCheat protocol in the current paper differs from the one 
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presented in [3]. 


2 Setup and Target UC Functionalities 


We begin by formalising tamper-evident distinguishable envelope through 
an ideal UC functionality, which is similar to the one formalised in [22]. To 
relate more closely to Moran and Naor’s work [22], we then introduce a weak 
bit-commitment functionality Fcc scrneaiepeneats q € (0,1), which is similar 
to that of [20, 22]. In this functionality, a sender decides whether to cheat at 
the very beginning (i.e., in a protocol, at the phase of envelope sealing) and 
the probability of potential cheating is controlled by the fact that the sender 
can be caught in certain cases (i.e., in a protocol, due to certain choices by the 


: 7 ? eu q- q—-WBC 
receiver). Then, we give functionalities Fyj.natcommitment 22d 7 caridt pening) 
q—-WBC 


which are different from Fg.capetnenMaycheat (i-e., a sender can decide to 
equivocate his commitment only at some point during the commitment 
phase or at some point during the opening phase, respectively). These 
—WBC —WBC . Ds 

Fe sh Gena eae eC. PF earuk omen functionalities are closer to standard 
weak bit-commitments [12, 1] and are better suited to both the theoretical 
and practical motivations mentioned in the introduction (e.g., the sender 
only decides to cheat in his commitments within an auctioning protocol once 
the receiver has already proven to be untrustworthy). 


2.1 UC-Setup Functionalities Modelling Tamper-Evident En- 
velopes 


The FP *.a1 Functionality for Tamper-Evident Distinguishable Sealed 
Envelopes 

The functionality FP%.,, models a tamper-evident “envelope”, distin- 
guishable by some obvious mark (e.g., barcode, serial number, colour, etc.). 
Protocol parties can simply open such containers, but any such opening will 
be obvious to other parties who receive the “torn” envelope. 

The functionality stores a table of the form (id, value, holder, state), 
indexed by id. For one fixed identifier id, the corresponding values are 
denoted as follows: valuejg, holderjg and state;g. In the presence of parties 
P,,...,Py and an ideal adversary Z, a run of the F241 ideal functionality 
is described as follows. 

Seal(id, value). Let this command be received from party P;. It 
creates and seals an envelope. If this is the first Seal message with id id, 
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the functionality stores the tuple (id, value, P;,sealed) in the table. If this 
is not the first command of type Seal for envelope id, then the functionality 
halts. 


Send(id, P;). Let this command be received from party P;. This 
command encodes the sending of an envelope held by P; to a party P;. Upon 
receiving this command from party P;, the functionality verifies that there 
is an entry in its table which is indexed by zd and has holder;g = P;. If so, 
it outputs (Receipt, id, P;, Pj) to P; and Z and replaces the entry in the 
table with (id, valuejg, P;, state;a). 

Open id. Let this command be received from party P;. This command 
encodes an envelope being opened by the party that currently holds it. 
Upon receiving this command, the functionality verifies that an entry for 
container id appears in the table and that holder;g = P;. If so, it sends 
(Opened, id, valueja) to P; and Z. It also replaces the entry in the table 
with (id, value;g, holderj;g, broken). 

Verify id. Let this command be received from party P;. This command 
denotes P;’s verification of whether or not the seal on an envelope has been 
broken. The functionality verifies that an entry indexed by id appears in the 
table and that holderj;q = P;. It sends (Verified, id, state;q) to P; and to T. 

One difference from the corresponding functionality presented in [22] 
is that the creator of an envelope cannot re-seal it, i.e., he cannot forge 
the value stored initially inside the envelope. Hence, the wording “OneSeal” 
refers the above functionality and the expression “MultiSeal” denotes the 
TE envelopes in [22]. (For consistency, in Appendix B, the reader can find 
the tamper-evident envelope functionality corresponding to [22]. We denote 
it Fyrnasest) 

Based only on creator-forgeable/multi-seal tamper-evident envelopes, 
we were not able so far to UC-realize sender-strong weak bit-commitments 
as we wanted them, i.e., UC-simulatable somewhat binding and not partially 
hiding, but computationally hiding bit commitment. We have not yet refuted 
the existence of such a construction either. 

Our change from FR sea, to FP%.a, brings the latter functionality 
closer to regular commitment than the tamper-evident functionality in [22] 
was. It is relatively easy to see that regular bit-commitments can be im- 
mediately constructed using one distinguishable tamper-evident envelope 
(see Section C of the Appendix, for the F?° UC-functionality of regular 
bit-commitments). The relation with the regular commitment functionality 
is however not symmetric, as Section 4 will detail (ie., if F-2%,.,, implies 
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BC, it is not necessarily the case that F2%,,, implies DE). But, as we said 
in the introduction, it is of stand-alone theoretical importance to be able 
to construct “error-tolerant” bit-commitments which are sender-strong, i.e., 
q-weak bit-commitments. 

Another, less significant difference from the corresponding functionality 
presented in [22] is that the F?” introduced above does not output tuples 
containing the creator’s identity. This would have been of no interest for 
the protocols constructed in the following and would hinder EUC-security 
proofs given later. 


2.2 Target UC Functionalities of Bit-Commitment 


We now describe our target functionalities Fi WPS that respectively model 
different weak bit-commitment (WBC) protocols, where we have 

x € {EscapeThenMayCheat, LearnAtCommitment, LearnAtOpening}. In this 
fashion, we can relate the WBCs UC-realized herein both with tradi- 
tional weak bit-commitments [1] of theoretical importance (e.g., see our 


Eee 7c eee and with weak bit-commitments UC-created in [22] with 


ae —WBC . 
distinguishable envelopes (see our Fracapatnasmapanane,): The differences be- 


tween these target-functionalities lie mainly in learning that equivocation is 

possible (yet not obligatory) at the commitment phase (2 eres 
: q—-WBC 

or the opening phase (Fi csnabeppanidg 


has not yet been caught abusing the protocol ( 


) vs. cheating only when the committer 


FI- WBC 
EocapeTheniaychust) - 


The Foc a aiace functionality idealising g-weak bit-commitment. 
Let q € (0,1). The functionality maintains a variable bit, where bit 
ranges over {0, 1,O}. 
Commit b. When the Commit b command (b € {0,1}) is sent to 
the functionality by a sender S, the value 6} is recorded in the variable bit. 
The i alae ne functionality outputs Committed to the receiver R 
and to the ideal adversary Z. Further commands of this type or of type 
EquivocatoryCommit below are ignored by the functionality. 


EquivocatoryCommit. When the EquivocatoryCommit command 
is sent to the functionality, the Fa er inte functionality replies to the 
sender and the ideal adversary with a | message, with probability 1 — q. 
With probability gq, the functionality sets the variable bit to the value U, 
outputs Committed to the sender, the receiver and to the ideal adversary. 


Further commands of this type or of type Commit above are ignored by 
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the functionality. 

AbortCommit. When the AbortCommit command is sent to the 
functionality, the Pe este functionality replies to the sender, to 
the receiver, and to the ideal adversary with a 1 message (denoting an 
abnormal end of the execution). Further commands are ignored. 

Open. Upon receiving the command Open from the sender, the func- 
tionality verifies that the sender has already sent the Commit b command. 
Then, the Fi. aematiext functionality outputs (Opened, bit) to the 
receiver and to the ideal adversary. Further commands are ignored by the 
functionality. 

EquivocatoryOpenc. Upon receiving the EquivocatoryOpen c 
command from the sender, with c € {0,1}, the functionality verifies that 
bit = O. Then, the functionality oi ree outputs (Opened, c) to 
the receiver and to the ideal adversary. Further commands are ignored by 
the functionality. 


In this functionality, the binding property of commitments can be defied. 
It corresponds to the weak bit-commitment functionality used by Moran and 
Naor [22], but it applies to the sender-strong case. In that sense, a dishonest 
player decides to try and open his commitment to any value even from the 
very beginning of the protocol and he can be successful in doing so with a 
probability of g € (0,1), once he has not been caught red-handed. 

Note that the WBC functionality presented above and the ones to be 
presented further model single bit commitments. Yet, they can easily be 
extended to respective functionalities for multiple commitments: i.e., each 
Commit b command sent by a sender S aimed at a receiver R would become 
Commit(id, b, R) and each corresponding functionality would store a tuple 
(id, sender, receiver, value) for each commitment, doing the respective checks. 


The Foe connitment functionality idealising q-weak bit-commitment. 

Let q € (0,1). The functionality maintains a tuple (bit, equiv), where 
bit ranges over {0,1} and equiv ranges over {“Yes”, “No”}. 

Commit b. When the Commit b command (b € {0,1}) is sent to the 
functionality, the value b is recorded in the variable bit. With probability q 
the value “Yes” is stored in equiv or, with probability 1 — q the value “No” is 
stored in equiv. The Face functionality outputs Committed to 
the receiver and to the ideal adversary. The Fo naa eee functionality 
outputs the updated value of equiv to the sender and to the ideal adversary. 


200 I. Boureanu, S. Vaudenay 


Further commands of this type are ignored by the functionality. 

Open. Upon receiving this command, the functionality verifies that the 
sender has already sent the Commit ) command. Then, the fs ee 
functionality outputs (Opened, bit) to the receiver and to the ideal adver- 
sary. Further commands are ignored by the functionality. 

EquivocatoryOpen. Upon receiving this command, the functionality 
verifies that the sender has already sent the Commit b command. Then, 
the functionality checks the value of equiv. If the value is “Yes”, then 
FeoarnatCommitment OUtputs (Opened, bit) to the receiver and to the ideal ad- 
versary. If the value is “No”, then Fe ase enti 
are ignored by the functionality. 

The 1 ee functionality mirrors a protocol which allows the 
sender to cheat by breaking the binding property of the protocol. Note 
that this cheating possibility is “decided” at the commitment phase, i.e., it 
is at some point during the commitment phase that the potential cheater 
learns about his opportunity. Also, note that while the cheating is allowed, 
it does not necessarily need to happen (i.e., there are two distinct opening 


commands). 


halts. Further commands 


In the next functionality equivocation becomes clear only at the opening 
phase. 


The Fie. icopening functionality idealising q-weak bit-commitment. 

Let g € (0,1). 

The functionality maintains a variable bit, ranging over {0, 1}. 

Commit. When the Commit b command (b € {0,1}) is sent to the 
functionality, the value 6 is recorded in the variable bit. The Egret ee 
functionality outputs Committed to the receiver and to the ideal adversary. 
Further commands of this type are ignored by the functionality. 

Open. Upon receiving this command, the functionality verifies that the 
sender has already sent the Commit b command. Then, the Pra cine 
functionality outputs (Opened, bit) to the receiver and to the ideal adversary. 
Further commands are ignored by the functionality. 

EquivocatoryOpen. Upon receiving this command, the functionality 
verifies that the sender has already sent the Commit 6 command. With 


probability g, the a pel ee outputs (Opened, bit) to the receiver and 
q-WBC 
sends | to 


to the ideal adversary. With probability 1 — q, the Fy earnatopening 
the sender S and the ideal adversary Z. Further commands of this type are 


UC and EUC Weak Bit-Commitments Using 
Seal-Once Tamper-Evidence 201 


ignored by the functionality (but commands of type Open are still allowed). 

The Pa aceite functionality mirrors a protocol which allows the 
sender to cheat by breaking the binding property of the protocol, knowingly 
at some point during the opening phase, i.e., it is at some point during 
the opening phase that the potential cheater learns about his opportunity, 
similarly to traditional lines in [1]. As aforementioned, note that while the 
cheating is allowed, it does not necessarily need to happen. 

Sender-strong (amplifiable) weak bit-commitments protocols with dis- 
tinguishable, tamper-evident envelopes that allow only partial hiding are of 
course easier to UC-construct than those that require perfect hiding (see 
Section 3.5). As aforementioned, we believe however that sender-strength 
brings with it the need for more than just partially hiding primitives, hence 
the “computationally hiding” UC functionalities advanced above. We seek to 
UC-realize just protocols, which proves to be non-trivial. 


3 UC (Sender-Strong) Bit-Commitments 


Driven by the theoretical and practical motivations presented in the intro- 
duction, we now give WBC protocols which are UC-secure, sender-strong 
and use TE distinguishable envelopes as setups. 


We will present the protocols Pass&MayCheat, CommitEnablesCheat 


; : 4—WBC 
and OpenEnablesCheat which respectively UC-realize P Padanethailayenant! 


rome nba ae ing FP... We th 
LearnAtCommitment 411 LearnAtOpening’ USING J OneSeal: e then present am- 


plification techniques of such weak BC protocols. The techniques maintain 
the lightweight character of the constructions. We conclude the section 
by a strengthening of the F24,., functionality such that we attain EUC- 
security [9], ie., not only UC-security. 


3.1 PasskMayCheat —- a SS-WBC protocol a la Moran and 
Naor [22] 


The Pass&MayCheat Protocol (see Fig.1): 
The illustration of the protocol in Fig. 1 is given in a symmetric way 
(i.e., E, and E» could be interchanged in their appearances, etc.). 


The Phase of Commitment and/or EquivocatoryCommitment. 
A sender S' seals four envelopes and creates two pairs out of them 
such that each pair contains the set {x,2} of values, for a randomly fixed 
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S R 
seal the bits bj, be, bs, ba, E, from P,, E3 from P, 
° ; ————__— 
in env-pairs P; = (Fi, E2), remember ids 1, 3, ie., W = {1, 3} 


Py = (E3, £4) s. t. the contents give 
the ordered tuple (x, 2,0, 1) 


or (x, x,y, y), with x,y € {0,1} {Fy, Es} 
1, £3 


continue if {£,, E3} 


E> from P,, E, from P, 
have not been tampered — 


check ids 2,4 ¢ {1,3}, rmb. ids {2, 4} 


El open E2 
e (note that Ly and FE; to-be-requested form 
the P; pair 
check Ey for tamper © Pi pair) 
(after sending E, below, 
S will be left with pair P2) 
FOR Commit: 
let d be b@ hi, Eid 
Le {3,4} se check 1 € {1,3}; open Fy, if by 4 be, abort 
FOR EquivocatorialCommit: 
let d € {0,1} 
Ey,d ip 
> check 1 € {1,3}; open Fi, if b) 4 be, abort 
(denote by A the pair of envs. on this side) 
FOR Open/Equivocatorial0pen: 
let Ex € A be E 
one of the envs. on this side  — check if k is an index for what should now 
be on $’s side; if passed, open E, and 
set b’ to d & by; 
if not passed, halt 


Fig.1: The Pass&MayCheat Protocol 


x € {0,1}. For a never-cheating sender, each pair “contains” its own value x. 
For a sender who may equivocate later, one pair contains the set {x, x} of 
values, for a randomly fixed x € {0,1} and the other pair contains the values 
{0,1}. The senders sends two envelopes, one from each pair, to the receiver 
R. (E.g., The pairs are: 1st pair P; = (£1, F2), 2nd pair P2 = (£3, E4) and 
S sends, e.g., E,, 3 to R). Then, the receiver R stores the identifiers of 
the envelopes in a register W. (L.e., it stores (1,3), given the illustrated 
execution by S in Fig.1.). Then, R sends them back without opening them. 

At this step, the sender S' verifies that the recently returned envelopes 
have the seals unbroken. If this is not so, he halts. Otherwise, he sends the 
two envelopes not sent before. (I.e., If seals are unbroken, then S sends the 
remaining 2, E4 as per Fig.1 .) 

At step four, the receiver verifies that the envelopes received do not 
have the ids stored already. If their ids have been already stored, he halts. 
Otherwise, he opens one of these envelopes, sends back the other one without 
opening it, together with the value of an zd stored already in W. The latter 
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is in sign of requesting back the envelope with that id. The receiver also 
stores the ids of the envelopes seen this time round. (Le., R opens, e.g., Fe, 
sends back FE, and the id, e.g., 1, as 1 © W. Thus, R would request back 
envelope £}.) 

Given the steps of the protocol so far, note that the envelope opened last 
together with the one requested last form an initial pair, which will now 
be found at R’s end. Also, once the sender has sent this lastly requested 
envelope, the sender will be left with the other of the initial pairs at his end. 

The sender S verifies that the recently returned envelope has the seal 
unbroken. If this is not so, he halts. Otherwise, he sends the one requested 
envelope to R. The non-equivocating sender sends the value d=b © b;, where 
b is the bit he is committing to and b; is the bit hidden inside each envelope 
in the pair to be found at his side. (I.e., If the seal is unbroken, then S 
sends the requested £1, d=b © bj, where }; is in E3 and/or in £4). The 
equivocating sender just sends a bit-value d. 

Finally, the receiver R opens the last envelope received and checks if 
the values at its side are equal. If not, he aborts. (Le., If £; and E> do not 
contain the same value, then R aborts). 

Let A denote the pair of envelopes to be found at this stage on the 
sender side. 

The Phase of Opening and/or EquivocatoryOpening. 

The never-cheating sender S$ sends one envelope Ex in the remaining 
pair A, ie., Ey € A or k € {i,j}. In turn, an equivocatorial open goes as 
follows: the sender S sends from the remaining pair A the envelope Ex, that 
contains the bit d@c, where c is the bit that the sender wants to open to. 

Then, the receiver R checks that E; is in the set A (by checking the ids). 
If this is the case, then R opens the envelope E; and he assigns d© by to the 
commitment-bit b’, where b; is the value that R finds inside E,. Otherwise, 
the receiver halts. 

Explanations on the PasskMayCheat protocol. 

Consider that the sender S would not like to equivocate, i.e., his en- 
velopes contains the set {z,x} of values per pair. Firstly, consider that 
his value d is calculated as if no equivocation is to take place. In such 
circumstances, at the opening phase, this sender is obliged to open correctly, 
i.e., to the initially committed bit. Secondly, consider now that S' does not 
form d as it is required, but that the receiver R were to follow the protocol. 
In this case, S may not be able to open. 

Assume now that the sender S may want to equivocate, i.e., S’s pairs 
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of envelopes contain the set {x,x} and {0,1}, respectively. In this case, 
it is down to the choices of R whether this sender is able to continue the 
protocol; obviously, S may be caught and the protocol halts in half of the 
cases (the possibility that a randomly chosen bit x is equal either to 0 or to 
1, depending which was the opening of R). In the other cases, $ will clearly 
be able to open the value d to any bit-value, since the pair A of envelopes 
left at his end will contain x and 7@. 

The fact that receiver-forgeability is noticeable and the fact that the 
protocol is designed in a staggered way mean that R can neither open 
envelopes that he is not supposed to open nor open too many envelopes (i.e., 
if he wanted to break the hiding property). 

The seal-once character of the envelopes prevents the sender S' from 
changing a value x once it is stored inside the envelopes. I.e., Say that S' 
reaches step 4 of the commitment phase and realizes that he will be caught 
by R, then S cannot act and change such a value x to prevent being caught. 


Theorem 3.1 In a hybrid UC-model, where the setup is the Fp %,.4, func- 


: : 4—WBC 
tionality, the Pass&MayCheat protocol UC-realizes the Fz. 


'scapeThenMayCheat 
functionality. 


Proof: We technically need to prove that any attack that happens in the 
é ‘ . 2—WBC 

real world can be simulated in the ideal world where the Fg. -apethenMayCheat 
is running. We divide this in two (logical) parts: A corrupts the sender 


(Alice) and A corrupts the receiver (Bob). Other cases are trivial. 


A corrupts the sender (Alice). 


The commitment phase. Z simulates A(Alice), its interaction with 
Fee. sa, and the protocol on Bob’s side. We distinguish three cases. 


I. A creates two pairs of envelopes, each containing the values {x, x}, for 
some x € {0, 1}. 


TZ’s simulation of Bob will receive envelopes and send them back as per 
the protocol. 


If A checks that the envelopes returned by Bob are indeed sealed, then 
T simulates a (Verified, id, ok) reply sent by F2 4,41. 


T continues any simulation until A(Alice) sends a bit d to Bob. 
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T chooses a bit b” such that b’=d @ x, where z is the value inside the 


envelopes left on the side of the A(Alice). The ideal adversary Z sends 


1 
+_WBC 


Commit b” to the Fg.capetnenMayCheat functionality. 


II. A creates two pairs of envelopes, one containing the values {x, x} and 
the values {0,1}, for some x € {0, 1}. 
The ideal adversary Z sends EquivocatoryCommit to the 


3-WBC ‘ : . . 
EscapeThenMayCheat functionality. If the functionality answers |, then 


the ideal adversary Z simulates Bob opening such that he is eventually 
seeing the {0,1}-pair, and he is then halting to A. Otherwise, he 
simulates Bob sending, in stage, the pair containing {0,1} back to A. 


If A checks that the envelopes returned by Bob are indeed sealed, then 
T simulates a (Verified, id, ok) reply sent by F2%,... 


T continues any simulation until A(Alice) sends a bit d to Bob. 


III. A creates two pairs of envelopes, each containing the values {0,1}. In 
this case, Z sends AbortCommit to the functionality and simulates 
Bob halting in front of A. 


The opening phase. 
TZ awaits for Bob to be sent an envelope Ey, from A. The simulation 
now depends on what A did at the commitment phase (i.e., recall that Z 


distinguished two cases based on the values sealed by A, which he knew). 


; 3-WBC 
If it was case I above, then Z sends Open to the Fg. capethenMayCheat 


functionality. 


If it was case II above, then Z sends EquivocatoryOpen c to the 
1 
+_WB : ; : : 
Osa uataeae functionality, where c is calculated as d @ by with b;, the 


value hidden inside envelope Ex. 


Lemma 3.1 For any environment machine Z and any real adversary A that 
corrupts only the sender, the output of Z when communicating with A in the 
real world is identically distributed to the output of Z when communicating 
with Z in the ideal world. 


The proof of the above lemma follows from the detailed simulation 
above. 
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A corrupts the receiver (Bob). 


In this case, Z simulates the real-world interaction of Alice with A(Bob) 
and with Bere. q, and Z corrupts dummy-Bob in the ideal-world. 

Note that, in all this, Z does not need to “commit” to the contents of 
the simulated envelopes but at the time of the opening. 

We begin with the simulation of the commitment phase. The ideal 


adversary Z waits for Committed or | to be sent by the functionality 
3—WBC 
2 


EscapeThenMayCheat: (No matter what command EquivocatoryCommit or 


Commit was sent to poe by dummy-Alice paumpites 
EscapeThenMayCheat ry. Y » “ EscapeThenMayCheat 


will send just Committed or 1). 


1 
5 —-WBC ; 
If 1 was sent by FescaperhenMaycheat» then Z creates four simulated 


envelopes, each pair containing {0,1}. No matter what opening A(Bob) 


makes, Z will simulate an abort from the commitment phase (i.e., send 


AbortCommi cane 
ortCommit to F tscapeThenMaycheat) 


1 
; F 5 —-WBC 
Now consider the case that Committed was sent by Fg.capeTnenMayCheat: 


Then, Z prepares four simulated envelopes for A(Bob), the content of which 
is not determined at this stage (as we anticipated above): if A(Bob) opens 
two envelopes from one initially formed pair, then Z gives results (simulating 
Be a) consistent with Alice not trying to equivocate or passing the 
equivocation. 

Equivalently, for the first envelope to open from an arbitrarily fixed 
pair, Z makes it open to a random value; for the second envelope from such 
the same pair, Z makes it looks as if it had the same value. Namely, when 
A(Bob) opens two envelopes, their content is set to the same random bit and 
the two remaining envelopes are set to two different random bits. Again, this 
simulates a successful equivocatorial commitment: i.e., the ideal adversary 
T needs to choose a permutation 7 € S4 such that t=(zx, 2,0, 1), to place in 
the simulated envelopes in a delayed way. (As expected, Z will eventually 
see the value of the bit committed by dummy-Alice and, with this strategy, 
T will be able to equivocatorially open to that bit.) 

If A(Bob) opened an envelope that he should not have opened (i.e., 


both in one packet of two sent in step 2), then Z sends Halt to the 


+—WBC . : F : 
EscapeThenMayCheat functionality. If Z got to this point, then he sends 


d € {0,1} to A(Bob). 
We continue with the simulation of the opening phase. As anticipated 
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above, the ideal adversary Z waits for (Opened, b) to be sent by the 
1_WBC te ede 

EscapeThenMayCheat functionality. 
It is now that Z needs to send A(Bob) an envelope FE; containing a 


bit 6; such that E; is consistent with the alleged permutation 7 € S4 that 
T used in the commitment phase (by appears in the permutation), Ex is 
consistent (w.r.t. ids) with A(Bob)’s opening, and by = d@b. Note that these 
constraints can always be satisfied giving the simulation in the commitment 
phase by Z. So, Z sends this envelope Ex to A(Bob), which will “accept” the 
opening. 

From the simulation above, together with the lemma within, it follows 


that the PMC protocol is UC-secure, realizing the 5-weak bit-commitment 


1 

5 —-WBC 

5 : 5 

functionality F iscapeThenMayCheat * 


3.2 The CommitEnablesCheat and OpenEnablesCheat Protocols 


In Fig.2 we present the CommitEnablesCheat protocol and in Fig.3 we give 
the OpenEnablesCheat protocol. The detailed explanations on these follow 
hereafter. 

The CommitEnablesCheat Protocol (see Fig. 2): The Commit- 
ment Phase. The sender wants to commit to a bit b and proceeds as it 
follows. 

First, the sender S creates 3 sealed envelopes denoted E\, E2, E3 
respectively containing the bits denoted 01, bo, 63, such that not all bits are 
equal. The sender sends the envelopes over to the receiver R. 

Then, the receiver memorises the ids of the envelopes in the set { F), Eo, E3} 
and sends them back to the sender. 

The sender now verifies that the envelopes sent back are untampered 
with. Then, he computes m as the majority of the bits sealed inside, i.e., 
m=M AJ(by, b2, b3). The sender wants to commit to a bit b. He calculates 
d=b@m. Then, the sender sends d to the receiver. 

At this step, the receiver sends the identifier i of an envelope that 
the sender should dispose of, i.e., i € {1,2,3}. (This means that the 
content of envelope i will not count further in the protocol.) Let the set 
A={ FE), E2, Ez} \ {E;} denote the set of remaining envelopes. 

Finally, the sender disposes of envelope i. (Note that after this the 
sender can equivocate if the remaining envelopes contain different bits.) 

The equiv value is 3. 

The Opening Phase. 
The non-equivocating sender sends an envelope Ey such that bh.=m. 
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R 
remember {F), Ez E3} 


S 
pick 61, b2, 63, not all equal 
Real Gn Dh etL2.a 


check E,, Eo, £3 for tamper 
take m= MAJ(bx, bo, b3) 
let dbe b@m 


ick 4 in {1,2,3 
dispose of E; { } 


Opening: 


honest $ test: Ey is in {F,, Fy E3} \ {E;} 
if passed, open Fy; 
set b! to d@ by 

ao Cerrar if not passed, halt 

EQULUOCALOTY Ex with bh=™m test: Ex is in {F, EF E3} \ {E;} 
if passed, open Ex; 
set b' todd by, 
if not passed, halt 

Fig.2: The CommitEnablesCheat Protocol 


S R 
pick 61, be, bs, not all equal Fy, Ey, F3. 
seal be in ‘Bet € {1,2,3 remember the ids in {F,, E2 E3} 


check FE), £2, E3 for tamper Fy, Eo, E: 
take m= MAJ(b1, bo, b3) oe 


let d be bm 


Opening: 
honest S 


equivocatory S 


: ara ee 7 
any S 1 set b := d® b 
epee of EF; pick i in {1, 2,3} 


honest S test: Ey is in {F1, Ey E3} \ {Ei} 
if passed, open E; and 
test b= by; 
if not passed, halt 
Ex with bk=T test: Ex is in {Ey, Ey E3} \ {Ei} 
if passed, open E; and 
test b= by; 
if not passed, halt 
Fig.3: The OpenEnablesCheat Protocol 


equivocatory S 
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The equivocating sender sends an envelope Ey such that b,.=™m. 

Then, the receiver tests that E;, € A and if so, he sets b’, the commitment 
bit, as follows: b’=d & by. If the test fails, the receiver halts. 

Note that by being asked to discard’ an envelope at the opening phase 
instead of in step 4 of the commitment phase, the idea behind protocol Com- 
mitEnablesCheat can be shaped to obtain a protocol where the equivocation 
becomes clear only at the opening time. The protocol obtained in this way 
is hereby denoted OpenEnablesCheat. The protocols CommitEnablesCheat 
and OpenEnablesCheat are graphically represented in Fig. 2 and Fig. 3, 
respectively. 

The OpenEnablesCheat protocol is very similar to the other protocol, 
CommitEnablesCheat, as we said. We will hereby only state the main differ- 
ences between the two. In the OpenEnablesCheat protocol, the discarding 
of the envelope is made at the opening phase. In a sense, the sender first 


“announces” how he will open his commitment by sending i (i.e., if it is an 


equivocal opening the sender will send inside é the negation of m, otherwise 
he sends m). Then, the receiver finally asks for the discarding of the one 
the envelopes that is at the end of the sender. After this discarding, the 
sender has to send Ex, i.e., the envelope with the k identifier. Depending 
which discarding was called for, the sender may or may not be able to send 


over one envelope E; that contains the same by as it was announced via b. 
Clearly, these steps are emulating the FrearnAtOpening functionality. 

Once again, observe that—unlike in the Pass&MayCheat protocol— the 
committer of the CommitEnablesCheat and OpenEnablesCheat protocols 
can cheat with some probability (i.e., 2), and this possibility is down to a 
mere choice of the receiver and it is not influenced by receiver being caught 
cheating. 

These requirements sound similar to looking for a means in which Alice 
would commit to a bit b using a BSC (binary symmetric channel) with noise 
level g [6]. However, all previous constructions [6, 12, 24] addressing this are 
not sender-strong, but receiver-strong. Moreover, they are designed within 
traditional lines, i.e., are not UC-secure. On a different note, those classical 
solutions are based error-correction codes (ECC) and/or pseudo-random 
generators (PRNG). In our case, PRNGs and ECCs are out of scope: we 
intend cryptographically lightweight primitives. And, CommitEnablesCheat 
and OpenEnablesCheat above deliver sender-strong, UC-secure, simple and 


4A possible way of implementing discarding is sending the emptied envelope back to 
the receiver. 


210 I. Boureanu, S. Vaudenay 


human operable primitives. 

Explanations on the CommitEnablesCheat and OpenEnablesCheat 
protocols. 

We detail only on the CommitEnablesCheat protocol above, counting 
on that the explanations on OpenEnablesCheat would very similar. We will 
now show that the protocol CommitEnablesCheat is complete. Assume that 
the parties adhere to the rules the protocol. In step 3, we would surely have 
m=z, if S had followed step 2 and S had produced the envelopes correctly 
(i.e., a permutation of {x,xz,z}, x €y {0,1} is sealed inside them). In this 
case, in the remaining set A there would always be an envelope FE, containing 
the value x that opens the commitment correctly. This is irrespective of 
the value 6; (be it x or Z). There is a probability of 2 for S to be able to 
open his commitment to the flipped bit (i.e., point 2 in the opening phase). 
Namely, this is in the cases where an envelope with value Z% is present in the 
remaining set A. Also, it is clear that S gains no benefit from not playing by 
the rules. Theorem 3.2 present these more formally, within the UC setting. 


Theorem 3.2 In a hybrid UC-model, where the setup is the Fp ",.,, func- 
tionality, the CommitEnablesCheat and OpenEnablesCheat protocols UC- 


3—WBC 3—WBC i) 
realize the FrearnatCommitment Nd the Frearnatopening Junctionalities, respec- 


tively. 


Due to heavy similarities between the case of CommitEnablesCheat and the 
case of OpenEnablesCheat, the proof of Theorem 3.2 is given in the for 
CommitEnablesCheat only. 


Proof: We technically need to prove that any attack that happens in the 


‘ : : 2—WBC ‘ 
real world can be simulated in the ideal world where the F;,.-na¢commit 18 


running. We divide this in two (logical) parts: A corrupts the sender (Alice) 
and A corrupts the receiver (Bob). The same sort of respective simulations 
by Z as in the previous proof are in place. 


A corrupts the sender (Alice). Hence, it is A who creates and sends 
the 3 envelopes, i.e., interacts with the F2%,.,, functionality. Note that Z 
intercepts the communication between A and the FP. functionality. So, 
TZ knows when J is cheating. 


The commitment phase. 
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I A has sent a valid pack of envelopes and the contents of the envelopes 
are an arbitrary but fixed permutation of (x,x7,%), where x €y {0,1} 
(i.e., b=, b9==ax and b3=%, up to a permutation). 


Bob will receive the envelopes and send them back. 


If A checks that the envelopes returned by Bob are indeed sealed, then 
T simulates a (Verified, id, ok) reply sent by F?%,.41- 


T continues any simulation until A(Alice) sends a bit d to Bob. 


T picks m/=M AJ(b1, ba, b3) (i-e., on this input, m/=2). I chooses a bit 
b” such that b”=d @m/!. The ideal adversary Z sends Commit b” to 


2 

=—WB ‘ ‘ A ‘ ‘ ; 
the Fa functionality. The functionality replies with a value 
for equiv, which is “yes” with probability 2 and “no” with probability 
$. If equiv is “yes”, Z picks 7 € {1, 2,3} such that b;=a and otherwise 


he picks 7 such that 6;=%. Z simulates Bob in sending 7 to A. 


II A has sent an invalid pack of envelopes, with all value inside equal to 
x, where x €y {0, 1}. 


TZ acts as in the case I above, but he sets equiv always to “no”. 


The opening phase. 

TZ awaits for Bob to be sent an envelope E; from A to see how A wants 
to open. The simulation now depends on what A did at the commitment 
phase (i.e., recall that Z distinguished two cases based on the envelopes 
sealed by A, which he knew). 


If it was case I of the commitment phase and b,=m/, then Z will send 
2—WBC 
3 


an Open command to the Fy,.,natcommit: 


If it was case I of the commitment phase and b,=m/, then Z will send an 


2-WBC 

EquivocatoryOpen command to the Fy.a-natcommit - (Note that because 
of the simulated 7 in the last step of the commitment, the ideal adversary is 
able to open the bit b” in the same way that the adversary would open his 


d.) 


If it was case II of the commitment phase, then by=m/ and Z will send 
2 WBC 
3 


an Open command to the Fy3,,,natcommit: 


Lemma 3.2 For any environment machine Z and any real adversary A 
that corrupts only the sender, the output of Z when communicating with A in 
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the real world is identically distributed to the output of Z when communicating 
with Z in the ideal world. 


The proof of the above lemma follows from the detailed simulation 
above. 


A corrupts the receiver (Bob) 

In this case, Z will have to create and send simulated envelopes for 
A(Bob). Note that the ideal adversary does not need to commit to the 
contents of containers from the beginning, since they influence the view of 
the environment only when they are actually open. 


The commitment phase. 

T sends 3 simulated envelopes to A. 

TZ continues the simulation until A sends the envelopes back. If A 
does not send the envelopes back or they are tampered with, Z assigns 
{x,x,Z} values to the envelopes at random and continues the simulation in 
the opening. A will be stuck in the protocol, eventually. 


The simulation through Z continues until it receives Committed from 
2—WBC 
LearnAtCommit ° 


T chooses d at random and sends this value d to A(Bob). 

Consider that, at the end of this phase, Z will identify the simulated, 
remaining envelopes by the set {1, 2,3} \ {i}, where 7 is picked at random. 
(There is no better strategy for A to pick 7 without opening envelopes.). 


The opening phase. 


2 
: re ; 3—WBC 
T waits until it receives (Opened, b’) from Fyy,.rnatcommit * 


Let bk be dev’. 
The ideal adversary Z will send an envelope k € {1, 2,3} \ {<} simulated 
and containing by : 


Lemma 3.3 For any environment machine Z and any real adversary A that 
corrupts only the receiver, the output of Z when communicating with A in the 
real world is identically distributed to the output of Z when communicating 
with LT in the ideal world. 


The proof of the above lemma follows from the detailed simulation above. 
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From the simulation above, together with the two lemmas within, it follows 


that the CommitEnablesCheat protocol is UC-secure, realizing the 3-weak 


2 

=—WBC 

: : ae 3 
bit-commitment functionality FP, .-natcommit - 


3.3 Amplifying g-WBC Sender-Strong Protocols 


Let KE {Pass&MayCheat, CommitEnablesCheat, OpenEnablesCheat}. Let 
x € {EscapeThenMayCheat, LearnAtCommitment, LearnAtOpening}. 

By using k instances of a g-weak sender-strong protocol of the 44-kind of 
protocols, we can obtain a protocol Amplified_ protocol that UC-realizes 
yo gs Hence, for a conveniently large k, we can attain regular bit- 
commitments. See the formalisations below. 

The Amplified_PasskMayCheat Protocol: 
(Equivocatory) Commitment Phase. 
The sender commits, all equivocally or all normally, to a bit b; in 


k sequential rounds, each time using the Fav ewe: functionality, 
j€ {1,...,k}. The j-th such functionality is denoted a ee As 


Each functionality Fee eri eiaat’ ; to which EquivocatoryCommit 
was sent, outputs to its sender Committed, with probability g and otherwise. 
If L is sent, then the receiver aborts. 
(Equivocatory) Opening Phase. 

The sender opens all commitments, equivocally or not, using the 
Fe a nseeed. F functionalities. The receiver halts if the openings are 
not all the same. 


Theorem 3.3 Let q € (0,1) and X be a security parameter. By using 
k=(X) instances of an Fle functionality, we can construct a protocol 
Amplified_s that UC-realizes the F?© functionality, where we have 

x € {EscapeThenMayCheat, LearnAtCommitment, LearnAtOpening} and K€ 
{Pass&MayCheat, CommitEnablesCheat, OpenEnablesCheat}. 


In particular, the protocol Amplified_Pass&MayCheat UC-realizes the 
k 
zt'—WBC 


EscapeThenMayCheat functionality. 


For the regular BC functionality, F?°, section C of the Appendix. 
The Amplified_Pass&MayCheat BC protocol is trivially following out of 
Amplified_Pass&MayCheat, i.e., where equivocation is not possible. By 
letting k=/2£ in Theorem 3.3, we make Amplified_Pass&MayCheat a ¢- 


log q 
weak bit-commitment, with ¢ arbitrarily close to 0. However, for protocol 
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Amplified_Pass&MayCheat to UC-realize F?°, we need a k to be of linear- 
size in the security parameter A. Proofs that weak bit-commitment protocols 
in the above sense can be amplified to regular bit-commitments exist already, 

, [24]. The proofs therein follow long-established lines, i.e., not the 
UC framework °. Also, they often refer to receiver-strong protocols and 
generally use more convoluted primitives, e.g., pseudo-random generators, 
error-correcting codes, outside our lightweight interests. Our proof is done 
in the UC framework and, as we can see, the protocol respects the sender- 
strong aspects sought-after herein. For simplicity, the proof is split between 
the three different cases: for the case of Amplified_Pass&MayCheat, see 
first lemma below; for the case of Amplified_CommitEnablesCheat, see the 
second lemma below; the Anplified_OpenEnablesCheat protocol is similar 
to Amplified_CommitEnablesCheat . 


Lemma 3.4 The protocol Amplified_Pass&MayCheat UC-realizes the 
Fi k_WBC 


EscapeThenMayCheat functionality. 


A corrupts the receiver. Note that the receiver cannot cheat using the 
functionalities provided. Hence, there is no attack in the real world to be 
simulated in the ideal world. 


A corrupts the sender. 


Commitment Phase. 

Let the bits used by A be denoted bj,...,b;. Moreover, let I C 
{1,...,k} denote the indices of those bits sent through the command 
Commit and J C {1,...,k} denote the indices of those bits sent through the 
command RquivecatoryCommit to different instances dees arene bo 
fe {l,...,k}. Also, let equiv; be the answer that Z simulates for A to re- 


Foes es € J (recall that equivj=Committed 


ceive eon each functionality 
with probability q and en, otherwise). 

The ideal adversary Z, upon seeing these commands, replies nothing 
to the ones of the Commit type and replies equivj=Committed to the 
commands of type EquivocatoryCommit, for all j € J. 


In the case that there is some j € J such that equiv; = L, then Z sends 


k_WBC 
AbortCommit to J adapatienitatiaat® 


°Similar proofs of amplifications may exist in the UC framework, however they would 
not be with respect to the F2~“?° functionalities as introduced in Section 2. 
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There are two cases completely describing the corrupt adversary’s 
behaviour: 


I. card(I) 40, i.e., A has sent some Commit commands®; 
II. card(I)=0, i-e., A has only sent EquivocatoryCommit commands. 


Case I above is completely described by the following sub-cases, depend- 
ing on whether A could ever possibly open his commitments to the same 
bit: 

I.1. In this case, there are two bits 6; and 6, of different values both 
sent through Commit commands, i.e., the set J of indices is non-empty and 
di,i’ € 1,i #7 such that b; 4 by. T sends Commit(0) to Fen eeices 
and stores that this was a special case. 

1.2. In this case, all bits indexed in the set J have the same value. Let 
us denote this value b;, 7 € I. However, the ideal adversary Z knows that 


equiv;=Committed for A, for all 7 € J. Z sends Commit(b;) to the ideal 


k 
: : q°-WBC 
functionality F; EscapeThenMayCheat* 


In case II above, the ideal adversary Z sends Equivocatory Commit 


k_ . . . 
to the Fea et ities functionality. Z gets an equiv answer back from 


k 
the Fees eieek functionality. If the equiv reply is negative, then Z 
halts (advising the real-world receiver to halt by an abort message as from 


an Fag functionality, 7 € J). 


Opening Phase. 

The opening phase follows on from the distinct cases discussed in the 
commitment phase. 

If it was case I.1 and Z has not halted in the commitment phase, then 
T halts now. Note that this models the real-world scenario, as —in this case— 
A will never be able to open to the same bit as he has sent two different, 
un-flippable bits, i.e., sent under Commit commands. Le., the real-world 
receiver will halt also at most at the end of the k openings. 

If it was case I.2 and Z has not halted in the commitment phase, then Z 
sends Open to the Fe ato functionality. Note that in this case, 
the opening will have the same 6; value as in the real world. 


If it was case II and Z has got a positive equiv back, then upon the 
Fy —WBC 


opening c of A, Z sends EquivocatoryOpen (c) to the Fg, capethenMayCheat 


®The notation card(S) denotes the cardinality of a set 9. 


216 I. Boureanu, S. Vaudenay 


functionality. 


Lemma 3.5 In the case above, the following holds. For any environment 
machine Z and any real adversary A that corrupts only the sender, the 
output of Z when communicating with A in the real world is identically 
distributed to the output of Z when communicating with Z in the ideal world. 


The proof of the above lemma follows immediately from the detailed 
simulation above. 


Lemma 3.6 In a hybrid UC-model, where a linear number of k instances 
of the c= eee are available as setup, the F®° can be UC-realized, 


where q € (0,1). 


Proof: Note that the receiver cannot cheat using the functionalities provided. 
Hence, there is no attack in the real world to be simulated in the ideal world. 


A corrupts the sender. 


Commitment Phase. 
Let the bits used by A be denoted bj,..., bj, in respective (Commit, b;) 
commands sent to the instances Fa cwabtieent pte becaght. 
TZ flips coins such that for each Fie omnitment: 1» 1t Simulates an equtvg 
reply being “yes” with probability gq and “no” otherwise, for @ € {1,...,k}. 
Then, having the bits 6; and the values equiv, the ideal adversary Z 
looks at the cases that A can be in: 


I. A could only open to the bit 0 (bg = 0 whenever equivg=“no” and there 
may be other equivy equal to “no”); 


II. A could only open to the bit 1 (bg = 1 whenever equivg=“no” and there 
may be other equivy equal to “no”); 


III. A could only open to any (this is the case if all equive=“yes”); 


IV. A cannot open to a consistent bit (this is the case if some equivg=“no” 
with bg = 0 and equivy=“no” with by = 1). 
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Note that for & as in the current lemma, the challenge protocol for the 
UC-environment is a game that is indistinguishable for the game where case 
III never arises. Using the difference lemma [25], we conclude that we can 
ignore the simulation by Z in this case. 

In case I and II above, Z sends (Commit, b) to the F?© functionality, 
b=0 in the first case and and b=1 in the second case. 

In case IV above, Z sends (Commit, ) to the F?© functionality, where 
b is a bit picked at random. 


Opening Phase. 

If it was case I or case II of the commitment phase, then Z simply sends 
Open to the F?© functionality (and this will reflect exactly the bit opened 
in the real-world). 

If it was case IV of the commitment phase, then Z sends a halting 
message to the receiver (that presumably the protocol to realize contains). 


Lemma 3.7 In the case above, the following holds. For any environment 
machine Z and any real adversary A that corrupts only the sender, the 
output of Z when communicating with A in the real world is identically 
distributed to the output of Z when communicating with Z in the ideal world. 


The proof of the above lemma follows immediately from the detailed 
simulation above. 


3.4 EUC-Insecurity of the CommitEnablesCheat Protocol in 
the FP"...,-hybrid model 


OneSeal 


Lemma 3.8 In a hybrid EUC-model, where the setup is the FP =... func- 


tionality, the protocol CommitEnablesCheat does not EUC-realizes the 
2_WBC ; 
F iarnstconadinent functionality. 


Proof: We will show that for a certain environment Z and a certain adversary 
A, there is no ideal adversary Z that perfectly simulates the protocol run by 
A to the environment Z. 

In an EUC FP#.,.,-hybrid model where the adversary corrupts the 
sender in the EUC real world, assume the following commitment phase 


execution. 
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The environment Z runs the Commit b protocol with 6 selected at 
random and A just relays messages and envelopes between Z and the 
receiver R. After the environment Z learns that R has actually received 
the Committed message, Z runs the Open protocol and compares the 
bit at R’s end to the actual chosen bit b. Clearly, Z cannot guess the bit 
b and cannot simulate perfectly the opening to 6 (i.e., decommit to 6 with 
probability 1). 

A version of Lemma 3.8 can be given for the rest of our WBC protocols 
and those in [22], i.e., the DE functionality as it is brings EUC-insecurity to 
the other WBCs too. 


3.5 (Stronger) Universally Composable Security 


In obtaining the UC-simulatability proof, details as small as the order 
of the messages in the commitment-phase of the weak protocol CommitEn- 
ablesCheat above and/or the amount of randomness given to the sender have 
huge impacts. To give but an example, imagine a protocol like the CommitEn- 
ablesCheat protocol where step 3 of the commitment phase becomes step 4 


and vice-versa. This minute change in the CommitEnablesCheat protocol 
. : hte op aT 2—WBC 
makes it lose its UC-security (i.e., the UC-realizability of F73 


earnAtCommitment is 
lost), while it keeps the protocol perfectly hiding and binding with probability 
2 in the classical sense. 

So, while it may seem easy to manipulate DEs to get weak BCs, it is the 
case that sender-strength and UC-security together are not trivially attained. 
(It is indeed easier to construct g-weak bit-commitments using a formalisation 
of distinguishable envelopes, when no UC-security or asymmetrical strengths 
are required.) 

Let us move to EUC-security. For a wrap-up on GUC (Generalised 
UC) or EUC (Externalised UC) see the Appendix, Section A.2. Imagine an 
EUC model with the F2%,,,,-setup. Further, consider an environment that 
creates the envelopes and gives them to the adversary. Then, in the ideal 
world, the simulator cannot “extract” the bit b to commit to and thus he is 
bound to fail to indistinguishably simulate the commitment phase. So, on 
these grounds, none of the protocols presented so far, nor those constructed 
previously in [22] for the receiver-strong case are EUC-secure or GUC-secure. 

To remedy the above (i.e., make the protocols herein and those in 
Moran and Noar’s work [22] EUC-secure), we present a slightly modified 
Fe ecar-setup. 
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FenrpotedDE'. A Stronger Functionality for Tamper-Evident Distin- 


guishable Sealed Envelopes 

This functionality stores tuples of the form (id, value, holder, state). 
The values in one entry indexed with id, like before. 

SealSend(id, value, P;). Let this command be received from an envelope- 
creator party P;. It seals an envelope and sends its id to the future holder P;. 
If this is the first Seal message with id id, the functionality stores the tuple 
(id, value, P;,sealed) in the table. The functionality sends (id, P;) to P; 
and to Z. (Optionally, it can send (id, sealed) to P; and to Z). If this is not 
the first command of type Seal for envelope id, then the functionality halts. 

Send(id, P;). Let this command be received from a holder-party Fj. 
This command encodes the sending of an envelope held by P; to a party P;. 
Upon receiving this command from party P;, the functionality verifies that 
there is an entry in its table which is indexed by id and has holderjg = P;. 
If so, it outputs (Receipt, id, P;, P;) to Pj and Z and replaces the entry in 
the table with (id, valuejg, P;, stateia). 

Open id. Let this command be received from a holder-party P;. This 
command encodes an envelope being opened by the party that currently 
holds it. Upon receiving this command, the functionality verifies that an 
entry for container id appears in the table and that holder;g = P;. If so, it 
sends (Opened, id, value;q) to P; and Z. It also replaces the entry in the 
table with (id, value;a, holderjg, broken). 

Verify id. Let this command be received from a holder-party P;. This 
command denotes P;’s verification of whether or not the seal on an envelope 
has been broken. The functionality verifies that an entry indexed by id 
appears in the table and that holderjq = P;. It sends (Verified, id, state;,) 
to P; and to Z. 

The essential modification from F241 to the Ferree’ aPF is that in the 
latter functionality an envelope is built for an intended holder. To this end, 
the purported destinator receives a notification of the form (id, creator), 
which indicates that his faced with a newly created envelope. If these 
envelopes were to be constructed by some real manufacturer, this company 
would ship its products to known/registered addresses. Thus, we believe 
that this modification is reasonable. A much stronger enhancement would 
have been to store or disclose the identities of the creators. This would be 


similar to signing the TE devices. We do not adhere to this behaviour for 
purpotedDE 
J OneSeal 


With this amendment, at a high level, we deter relay attacks. A receiver 
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will expect envelopes freshly created for him and parties will not be able to 
pass on, as creators, envelopes produced by other participants, i.e., Z will 
not be able to prepare envelopes for A, to be used as if A was their creator. 
Thus, the issue raised by Lemma 3.8 is rectified. 


Theorem 3.4 In a hybrid EUC-model, where the setup is the Fae a 


functionality, the protocol CommitEnablesCheat EUC-realizes the 
2_WBC 
3 


LearnAtCommitment functionality. 


Note: We have to note that the protocol in the theorem above is in fact 
the CommitEnablesCheat slightly changed to accommodate the use of pur- 
ported DE instead of simple DE. Le., it is where it is the setup functionality 
(e.g., a sort of creating-authority) which sends the created envelopes to the 
destinator, not the logical creator; and, further, the destinator must check 
the ID of the logical creator as announced by the functionality. 

The proof of the above theorem follows from the proofs of Theorem 3.2 
and that of Lemma 3.8, combined with the fact that Fpnrpoted DE envelopes 
have a specified entity as their destination and this entity knows this fact 
upon the creation of the envelopes. We conjecture that Theorem 3.4 holds 
even in the case of adaptive adversaries. 

A version of Theorem 3.4 can be given for the rest of our WBC protocols 
and those in [22], i.e., purported DE can bring EUC-security to the other 
WBCs too. 


4 Implication-Relations between (Weak) 
Bit-Commitments and Distinguishable Envelopes 


in UC 


From the work in [22] and the line herein, we can summarise that receiver- 
strong and sender-strong weak UC bit-commitment (amplifiable to BC) can 
be UC-realized with FP... (or Fee? aPE) We already know that the 
ideal functionality of F?° (see Fcom in [7]) is a sufficient UC-setup to 
realize ZK. The ultimate question in this context would be whether, e.g., 
Fee. sa: is sufficient for UC-secure ZK. But, we could first study the possible 
separations (within UC) between all these ideal functionalities, i.e., for BC, 
WBC, DE. 


Firstly, we can UC-realize an 


q—-WBC 
an. J TearaktOpstiing 


q—-WBC q—-WBC 
J acapeThadtiayOHwatts / Tearnktcommitaeht or 


functionality, for some qg € (0,1) by using just a multiple 
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commitment Fyycom [7] UC-setup. (For the Fizcom [7] functionality, please 
refer to Section C of the Appendix). In other words, to get a UC-secure sender- 
strong weak bit-commitment, we only need several instances of the regular 
bit-commitment functionality F?°. Namely, three F?© functionalities (see 
Section C of the Appendix) are sufficient to UC-realize a 2-WBC which 
is sender-strong. Imagine the protocol CommitEnablesCheat where three 
commitments using Fzyz;com or using three instances of F Be respectively 
and uniformly replace the three envelopes used inside. Let this transformed 
protocol be called ?. Obviously, P is a UC-secure SS-WBC build via Fas;com 


or F?°, The same mechanism would work to transform OpenEnablesCheat 


; : 2_WBC 
instead of CommitEnablesCheat and we would UC-realize F;° 


earnAtOpening? 
using a Fycom or fae setup. 

Secondly, all sender-strong weak BCs UC-imply regular BCs (following 
from Theorem 3.3). 

Thirdly, we conjecture that a bit-commitment setup is not enough to 
UC-realize the FP%,,,, distinguishable tamper-evident envelope functionality. 
This is mainly due to the difference in opening commitments and opening 
“envelopes”. The first are always open by their creator. If BC would UC- 
imply DE, then DE should also always be finally opened by their creator. 
Or, the latter could be possible only if the creator of the DEs would always 
know who the current holder of the DE is. This is not the case, hence our 
conjecture. 

If we take into about the amplification proofs as well, then we have 
rendered the picture of the UC-realisability of different flavours of sender- 
strong weak BC with tamper-evident envelopes, have drawn of their relation 
with (almost) regular BC and with receiver-strong weak BCs by Moran and 
Naor [22]. Also, we now can see that all weak BCs are equivalent to regular 
BCs, at some level. 

We leave the EUC or the GUC correspondents of the implications 
enumerated above as open questions. Also, it is in our future interests to 
investigate if flavours of tamper-evident devices can UC-construct ZK proofs 
of knowledge without passing through BC protocols. 


5 Conclusion 


We conclude that quite simple, distinguishable, sealed envelopes can create 
sender-strong (weak) bit-commitments protocols. This answers several 
practical needs [11, 18, 13], but also we can view it as answering a quicker 
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variant of the open question in Moran and Naor’s work [22]. 


We have also shown that the protocols in [22] are not EUC-secure but 


only UC-secure. We then showed how to modify the F2%,.,, functionality 
given in Moran and Naor’s work [22] such that we also create (weak) bit- 
commitment protocols that are EUC-secure. We illustrated lightweight 
amplification proofs of our WBC protocols. The implications between UC 
weak BCs, UC regular BCs and distinguishable tamper-evident UC envelopes 
were finally discussed. 
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A Overview on the UC and Enhanced UC Frame- 
works 


A.1 General Approach to UC proofs 


At some high level, a UC proof that a protocol is secure means to show that 
the environment (Z) cannot distinguish between the execution in the “real 
world” from the execution in the “ideal world” [7]. 

The “ideal world” contains “dummy” parties, the “target” ideal function- 
ality (that the protocol is emulating) and the “ideal” adversary, Z. The “ideal” 
adversary” Z can corrupt up to half minus one of the parties, in which case 
T will see the input of such a party, all communication sent to it, and Z can 
decide its output. Normally, these “dummy” parties simply send their inputs 
to the ideal functionality and wait for the response which they write on their 
output tape. The environment Z normally gives the inputs to the parties 
and reads their local outputs, can communicate with Z, but it does not have 
a direct input-output communication link with the ideal functionality. 

The “real world” contains protocol participants, the environment Z, 
the “real adversary” A and potentially ideal, “setup” functionalities. There 
can be up to half minus one parties corrupted by A (i.e., parties which 
may not follow the protocol) and A can communicate with Z and with the 
setup functionalities, if and when the latter are present. The environment Z 
has the same capabilities as in the ideal world (e.g., he cannot see internal 
communications). 

The protocol securely UC-realizes an ideal functionality, if there exists 
TZ such that for any Z and any A, Z cannot distinguish between the ideal 
world and the real world. Or, an alternative definition reads as follows: a 
protocol securely UC-realizes an ideal functionality, if for any Z and any A, 
there exists Z such that Z cannot distinguish between the ideal world and 
the real world [7, 9]. 


A.2 Enhanced UC frameworks 


This short summary on enhanced UC frameworks follows the work by Canetti 
et al. [9], where the reader is referred for further details. In the basic UC 
framework, the environment Z is able to interact with the adversary and with 
the general challenge protocol (i.e., the protocol distinguishing actual attacks 
in the real world from simulated attacks on the ideal, target functionality), 
but the environment Z is unable to invoke directly the setup functionalities. 
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While this is enough to get the composability theorem [8], it was shown 
to be impossible to UC-realize some protocols in UC with global setup, 
i.e., when protocols share state information with each other [9]. To bypass 
such impossibility results, strengthened UC frameworks were created [9], i-e., 
Externalized UC and Generalized UC. 

In GUC (Generalized UC), the environment Z is allowed to invoke and 
interact with arbitrary protocols (setup functionalities included) and even in 
multiple sessions of the challenge protocol. 

Additionally to a basic UC environment and restricting the GUC envi- 
ronment, the EUC (Externalized UC) environment Z is allowed to invoke a 
single external protocol instance. Any state information that will be shared 
by the challenge protocol must be shared via calls the shared functionality 
(here, F24.a1 Or similar distinguishable envelope functionalities) and the 
EUC environment is granted direct access to the shared functionality. 


B- The Tamper-Evident Envelope, 
Creator-Forgeable Functionality (as per [22]) 


The Fee sei Functionality for Tamper-Evident Distinguishable 
Sealed Envelopes 

This functionality for tamper-evidence stores a table of “devices”, in- 
dexed by their id. More precisely, an entry in this table is of the form 
(id, value, creator, holder, state). The values in one entry indexed by id are 
respectively denoted creatorjg, valuejg, holder;g and statejg. 

Seal(id, value). Let this command be received from party P;. It 
creates and seals an envelope. If this is the first Seal message with id id, 
the functionality stores the tuple (id, value, P;,sealed) in the table. If this 
is not the first command of type Seal for envelope id and the command 
comes from the envelope’s creator, then the functionality updates the stored 
value. If this is not the first command of type Seal for envelope id but the 
command does not come from the envelope’s creator, then the functionality 
updates the stored value. 

Send(id, P;). Let this command be received from party P;. This 
command encodes the sending of an envelope held by P; to a party Pj. Upon 
receiving this command from party P;, the functionality verifies that there 
is an entry in its table which is indexed by zd and has holder;qg = P;. If so, 
it outputs (Receipt, id, P;, P;) to P; and Z and replaces the entry in the 
table with (id, valueja, P;, state;a). 
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Open id. Let this command be received from party P;. This command 
encodes an envelope being opened by the party that currently holds it. 
Upon receiving this command, the functionality verifies that an entry for 
container id appears in the table and that holder;g = P;. If so, it sends 
(Opened, id, valueja) to P; and TZ. It also replaces the entry in the table 
with (id, value;g, holder;g, broken). 

Verify id. Let this command be received from party P;. This command 
denotes P;’s verification of whether or not the seal on an envelope has been 
broken. The functionality verifies that an entry indexed by id appears in the 
table and that holder;q = P;. It sends (Verified, id, state;q) to P; and to T. 


C Regular Bit-Commitment UC-Functionality 


The F’° functionality idealizing regular bit-commitment. 

Commit b. This command simulates a party (the sender) committing 
to the bit b in front of another party (the receiver). The functionality records 
b and outputs Committed to the receiver and to the ideal adversary. It 
then ignores any other commands until it receives the Open command from 
the sender. 

Open. This command simulates a party (the sender) opening a com- 
mitment in front of another party (the receiver). The functionality outputs 
(Opened, b) to the receiver and to the ideal adversary. 


The Fycom functionality idealizing multiple regular bit-commitment. 


(Commit, sid, cid, P;, Pj, b). Upon receiving this command from 
P;, with b € {0,1}, the functionality stores (cid, P;, P;, b) and it sends 
(receipt, sid, cid, P;, P;) to P; and the ideal adversary. It then ignores 
subsequent commands (commit, sid, cid, P;, P;,*) from P;. 

(Open, sid, cid, P;, P;). Upon receiving this command from P;, if a 
tuple (cid, P;, P;, b) for some bit 6 exists, then the functionality sends 
(open, sid, cid, P;, Pj, b) to P; and to the ideal adversary. Otherwise, 
the functionality does nothing. It then ignores subsequent commands 
(open, sid, cid, P;, P;) from FP. 
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